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Abstract. A communications service, called Path Service, is currently being developed 
by the Consultative Committee for Space Data Systems (CCSDS) to provide a mechan- 
ism for the efficient transmission of telemetry data from space to ground for complex 
space missions of the future. This is an important service, due to the large volumes of 
telemetry data that will be generated during these missions. This paper presents a prel- 
iminary analysis of performance of Path Service, with respect to protocol-processing 
requirements and channel utilization. 

1. Introduction 

The Consultative Committee for Space Data Systems (CCSDS) is an international 
organization that develops recommendations for data-system standards to support space 
missions. Member agencies include the National Aeronautics and Space Administration 
(NASA)/USA, the European Space Agency (ESA)/Europe, and space agencies in the 
United Kingdom, Canada, France, West Germany, India, Brazil, and Japan. Although 
CCSDS recommendations are not considered binding on any of the member agencies, 
adherence to the recommendations will provide compatibility of data-handling systems 
among cooperating agencies. This will facilitate collaborative ventures such as Space 
Station Freedom. 

Existing CCSDS recommendations apply to conventional space systems which 
serve a moderate number of users, at relatively low data rates. New CCSDS recommen- 
dations are being developed for advanced orbiting systems that are envisioned for the 
1990’s [3] (for example, manned and man-tended space stations, unmanned space plat- 
forms, and space transportation systems), to handle the high data rates (as high as 300 
megabits/second for synthetic-aperture-radar data and 450 megabits/second for data from 
the High Resolution Imaging Spectrometer) and large numbers of users which will be 
typical of these systems. Two major types of traffic that will contend for communica- 
tions resources in advanced orbiting systems are telemetry data and interactive traffic. 
Telemetry data will be transmitted using a light-weight communications service, called 
CCSDS Path Service. Interactive traffic will be transmitted using CCSDS Internet Ser- 
vice, which is based on the International Standards Organization (ISO) 8473 internet pro- 
tocol [4]. 

The purpose of this paper is to analyze performance of CCSDS Path Service, with 
respect to protocol-processing requirements and channel utilization. The analysis is prel- 
iminary, because it is premature to quantify processing aspects of the service until further 
development occurs. In Sections 2 and 3 we give an overview of the types of applica- 
tions that will be associated with advanced orbiting systems and the services, especially 
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Path Service, that are being developed by CCSDS to support them. In Section 4 we 
examine performance issues involved in each component of the Path Service process, 
from the instrument interface to processing at the ground terminus. In Section 5 we com- 
pare and contrast Path Service and Internet Service, with respect to functionality, perfor- 
mance bottlenecks, and appropriateness to support applications that are typified by the 
telemetry application. 

2. Advanced Orbiting Systems Protocols and Applications 

In this section we present an overview of Path Service and Internet Service, the two 
packet-transmission services that the CCSDS has defined for advanced orbiting systems. 
There are substantial differences between the types of applications that the two services 
are expected to support. 

2.1. Path Service 

Path Service is a special-purpose service developed by the CCSDS to provide an 
efficient, cost-effective means of transmitting large volumes of measurement data from 
earth-observing satellites to the end user on the ground. This type of data is called 
telemetry data. Data rates of current scientific instruments vary from less than 1 megabit 
per second to approximately 500 megabits per second. I nstrum ents will be turned on for 
long periods of time, possibly several hours or even months, producing a steady stream 
of data packets that must be handled by the communications system, including both the 
onboard subnet and the space-to-ground subnet. Some data compression may be per- 
formed for the higher-rate instruments, but the volume of traffic to b® transmitted to 
ground will still be enormous. Based on the rate at which the volume of data from 
earth-observing satellites has been increasing in recent years, NASA has projected that 
by 1995 the volume of telemetry data will be on the order of 3 gigabits per second [6]. 
Hence, efficient handling of telemetry data is essential. In fact, determining how to cope 
effectively with enormous amounts of scientific data is one of the most pressing problems 
faced by the agency today. 

Besides the sheer volume of data involved, handling of telemetry data is further 
complicated by the fact that individual unmanned platforms (on which observational 
instruments are normally located) are typically scheduled for only a 10- to 20-minute 
space-to-ground communications window per 90-minute orbit. Accordingly, most of the 
data from the observational payloads must be stored onboard, by recording it on tape, for 
transmission during the next communications window. To protect against loss of data, 
some of the data generated during the spacecraft’s period of contact is stored as well, 
causing an overlap between stored data and real-time data (i.e., data that has not been 
stored). Since rewinding the tapes before the data is played back for transmission would 
increase wear on the tapes, it is likely that recorded data will be transmitted to ground in 
reverse order. Because of these artifacts introduced by the space-networking environ- 
ment, preliminary ground processing, called Level Zero Processing (LZP), is needed to 
restructure the data before it is delivered to the end user. 
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2.2. Internet Service 

The CCSDS recommendation for advanced orbiting systems [3] also provides a ser- 
vice, called Internet Service, to support more conventional interactive networking appli- 
cations. This will be a new mode of operation for space-mission users, since onboard 
interactive local-area networking has not been provided in the past. Examples of appli- 
cations that are expected to use Internet Service include interactive scientific experiments 
and interactive command and control of the spacecraft and resources located on it. 
CCSDS has selected the International Organization for Standardization (ISO) 8473 inter- 
net protocol [4] as the basis for Internet Service, in order to provide adequate flexibility 
to support applications of this type and to facilitate interoperability between networks 
provided by different organizations. 

3. Path Service Overview 


3.1. Performance Objectives of Path Service 

Traditional performance measures of communications protocols are end-to-end 
delay and end-to-end throughput. Such end-to-end measures are somewhat inappropriate 
for Path Service, because of the delay incurred when data is recorded onboard. 

Resource limitations are a major concern for space networking. Stringent con- 
straints on power, weight, and volume limit onboard resources significantly. In addition, 
space-to-ground bandwidth is a scarce resource, because the channel must be shared not 
only by multiple spacecraft, but also by multiple space missions. Efficient use of both 
onboard resources and the space-to-ground channel is essential. Accordingly, the pri- 
mary performance objectives of Path Service are to minimize onboard protocol process- 
ing and to optimize use of the space-to-ground channel. Optimization of the handling of 
telemetry data, which is expected to account for 85 to 90% of all space-mission data, will 
have a significant impact on overall system requirements. 


3.2. Functionality of Path Service 

Path Service is designed to exploit the characteristics of the telemetry application. 
The nature of observational payloads and telemetry data are well understood. Once a 
payload has been configured, the communications requirements, including source- 
destination pairings, data rate, and data format, are static for long periods of time. 
Hence, it is possible to establish a communications infrastructure that will provide pre- 
cisely the resources that are required for support of a particular instrument. 

Path Service is based on the establishment of such an infrastructure. Network 
management preconfigures Logical Data Paths for telemetry data, completely specifying 
source-to-destination routing. At the same time attributes, such as data rate and data for- 
mat are associated with these Logical Data Paths. After configuration is completed, data 
can be routed across onboard subnets and the space-to-ground subnet by specifying only 
the Logical Data Path to be followed, rather than full source and destination addresses. 
No handshaking between the sender and the receiver during data transmission is neces- 
sary, because the preconfiguration process (along with careful scheduling of the various 
activities that will be sharing the communications resources) guarantees that each Path 
Service entity along the Logical Data Path can provide the services required of it before 
turning on the instrument. In this way Path Service creates a trunk for efficient 
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transmission of large volumes of data from space to ground.* 

3.3. Architecture of Path Service 

CCSDS Path Service does not map directly into the structure of the Open Systems 
Interconnection (OSI) network model, since users of Path Service don’t require all the 
functionality provided by the OSI protocol stack. CCSDS Path Service serves primarily 
as a routing service, so the Path Service layer serves as a network layer. However, no 
transport, session, or presentation services are required, so the Path Service layer inter- 
faces directly to the application above. The Path Service layer interfaces to the logical- 
link-control layer below. 

4. Performance Issues 

The transmission of telemetry data from the space-based instrument to the ground- 
based end user consists of the following sequence of events. Scientific instruments 
located on-board a spacecraft (probably unmanned) generate sensor data at a given rate. 
The instrument interface is a simple processor that formats instrument data into CCSDS 
Packets, the basic unit of transmission for Path Service data. CCSDS Packets are 
transmitted over an onboard subnet to a location where they are formatted for transmis- 
sion over the space-to-ground link. At this point data will probably be recorded for later 
transmission, since an unmanned space vehicle is likely to have limited contact with the 
ground. This recorded data will be transmitted to ground during the next communica- 
tions window associated with that spacecraft. Once it reaches the ground, the telemetry 
data will be forwarded to a finite number of locations, where network-induced artifacts 
will be removed by Level Zero Processing. From there the reco nstructed data will be 
forwarded to the end user via either public or private ground networks. 

Based on this description, an analysi s of the performance of CCSDS Path Service 
must address delay within the instrument interface, transmission over the onboard subnet, 
formatting for transmission to ground, transmission over the space-to-ground link, and 
Level Zero Processing on the ground. Another importa nt element o f Path Service is the 
role of network management in preconfiguring the communications infrastructure for 
telemetry transmission and in scheduling the use of limited onboard resources. We 
examine each of these components of the Path Service end-to-end process. 

4.1. Onboard Processing 

Components of onboard processing include the delay within the instrument inter- 
face and transmission over the onboard subnet. 


♦Path Service will be used to support other applications typified by the telemetry application, i.e., 
applications which have static communications requirements for long periods of time. These 
will likely include some space-to-space and ground-to-space applications. Since telemetry data 
accounts for the largest volume of Path Service data, by far, it is the only application we address 
in this paper. 
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4.1.1. CCSDS Packet Format 

The basic unit of transmission for Path Service is the CCSDS Packet, which has a 
header that is only 6 octets long. Figure 1 illustrates the structure of the CCSDS Packet; 
Table 1 explains the meaning of each of the fields of the primary header. 

It is reasonable to assume that all the fields of the primary header, except the Packet 
Sequence Control Field, will be fixed for a particular instrument. Use of such a simple 
packet structure minimizes the amount of protocol processing required both at the instru- 
ment interface and at Path Service entities along the Logical Data Path which need to 
parse the header to determine how to forward the packet, e.g., at gateways between sub- 
nets. 

4.1.2. Instrument Interface 

The instrument interface formats data into CCSDS Packets. Because most of the 
fields have a constant value for a given instrument, the packetization process is trivial. 
NASA engineers who are designing this instrument interface estimate that less than 
twenty medium-scale integrated circuits will be required. This design can be imple- 
mented on one integrated circuit board, using off-the-shelf technology. Implementing 
this instrument interface on a single chip, using VLSI technology, is a future possibility. 

The quantities that are important for onboard equipment are power, weight, and 
volume. The instrument interface described above, whether implemented as a single 
board or as a VLSI chip, has minimal requirements with respect to these three measures. 
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FIGURE 1. CCSDS PACKET STRUCTURE 
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TABLE 1. FIELDS OF CCSDS PRIMARY PACKET HEADER 


r Field 


Contents 

Packet Identification Field: 
Version Number 


Version of CCSDS Packet. 

Type 


Currently not used. 

Secondary Header Flag* 

1 bit 

Indicates presence or ab- 

Application Process ID 

11 bits 

sence of secondary header. 
Identifies Logical Data 

Packet Sequence Control Field: 
Sequence Flags 

2 bits 

Path. 

Indicates whether packet 

Packet Sequence Count 

14 bits 

is a first, last, or intermedi- 
ate component of larger 
user data structure. 
Sequential count of pack- 

Packet Length 

2 octets 

ets associated with this 
Logical Data Path. 
Length of packet. 


4.13. Onboard LAN Transmission 

After the packet is constructed, it will be transmitted over an onboard subnet, which 
may be either a local area network (LAN) or a point-to-point direct connection. For 
Space Station Freedom low-rate instruments will be connected to a LAN, while high-rate 
instruments will be directly connected to an onboard location where data is formatted for 
transmission over the space-to-ground link. Placing the low-rate instruments on a LAN 
enables them to share the same Virtual Channel (discussed in Section 4.2.1) on the 
space-to-ground link. 

We do not quantify channel efficiency on the onboard subnet in this paper, because 
it is dependent both on the type of subnet involved (i.e., whether the subnet is a local area 
network or a point-to-point connection) and on the selection of other network-layer pro- 
tocols that might be used in conjunction with Path Service. 

Processing at the onboard receiver, i.e., the location where data is formatted for 
transmission over the space-to-ground subnet, is minimal. Data arrives at a predeter- 
mined rate and in a predetermined format, based on the particular Logical Data Path, and 
the formatting procedure is a simple one (as indicated in Section 4.2). Since there are no 
connections in the sense of the OSI network model, there is no end-to-end handshaking. 
In particular, no mechanisms are provided for flow control or acknowledging receipt of 

data. 


♦Use of the Secondary Header is currently under consideration by the CCSDS. It will likely be 
used to specify ancillary data to help identify the user data. 
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4.2. Space-to-Ground Transmission 

The space-to- ground subnet, the communications channel between space and 
ground, provides services that correspond to the data-link and physical layers of the OSI 
network model. Special protocols have been defined for its use, because of the unique- 
ness of the space-networking environment. 

4.2.1. Channel Structure and Bandwidth Limitations 

Space-to-ground bandwidth is an extremely scarce resource, since it is so expensive 
to provide the channel. The protocol that the CCSDS has developed for the Space Link 
Subnet is patterned after time-division multiplexing, which is generally considered to 
provide the highest channel utilization in a heavily loaded network. Fixed-length data 
blocks from different Virtual Channels are interleaved on a single physical space chan- 
nel; consecutive data blocks are separated by synchronization markers. There is a single 
data-block length for all Virtual Channels that share the same physical space channel. 
Fill data is transmitted if necessary, so that data is transmitted over the physical space 
channel as a synchronous symbol stream, with synchronization markers appearing at con- 
stant intervals. This transmission pattern facilitates simple, robust synchronization 
processes at the ground terminus. 

NASA currently has three Tracking and Data Relay Satellite System (TDRSS) 
satellites in orbit, which constitute the space-to-ground subnet. Each provides two chan- 
nels which can transmit approximately 300 megabits per second from space to ground. 
Because TDRSS will be shared by all U.S. space missions, not only the various space- 
craft within the Space Station Freedom constellation, efficient use of this scarce resource 
is absolutely essential. 

4.2.2. Format of Coded Virtual Channel Data Units 

The basic data structure for transmission of telemetry data over the Space Link Sub- 
net is the Coded Virtual Channel Data Unit (CVCDU), i.e., a Virtual Channel Data Unit 
(VCDU) with Reed-Solomon Check Symbols appended to provide forward error detec- 
tion and correction. CVCDUs must have the same, constant length for a given physical 
space channel. Faster channels will be able to support longer CVCDUs. CCSDS Packets 
are multiplexed together to form a Multiplexing Protocol Data Unit (M-PDU), which 
then becomes the user data field of the CVCDU. The CCSDS Packet is the only packet 
type that is recognized by this multiplexing function; CCSDS recommends that a packet 
of any other type, including an Internet Packet, be encapsulated within a CCSDS Packet 
before transmission over the space-to-ground link. 

Many of the attributes of Virtual Channels are static, such as the length of the 
CVCDU, data-handling requirements at the ground terminus, maximum data rate, etc. 
The static nature of these attributes means that network management can preconfigure 
the structure of the various Virtual Channels, thus reducing the amount of information 
that needs to be specified in the CVCDU header. This results in a simple structure for the 
CVCDU There are several possible formats for a CVCDU, depending on the type of 
data contained in the user-data field. Figure 2 illustrates a CVCDU format which is rea- 
sonable to use for the transmission of telemetry data. The meaning of each of the fields 
presented in Figure 2 is given in Table 2. Note that the CVCDU header, including die 
M-PDU header, is only 8 octets long. Because of its simple format, minimal processing 
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is required to construct the CVCDU. 

4.2.3. Channel Efficiency for Space-to-Ground Link 

We compute channel efficiency, i.e., the ratio of the number of octets of user data to 
the total number of octets transmitted, for a Virtual Channel that transmits only telemetry 
data. We use the CVCDU configuration given in Figure 2 and Table 2, and we assume 
that all CVCDUs contain useful measurement data, i.e., there is no fill data. Since the 
length of the user data field of the CVCDU illustrated in Figure 2 is the largest possible 
value supported by the CCSDS recommendation, this configuration gives maximum 
channel efficiency. 
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FIGURE 2. CODED VIRTUAL CHANNEL DATA UNIT STRUCTURE 
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TABLE 2. FIELDS OF CODED VIRTUAL CHANNEL DATA UNIT 


Field 

Length 

Contents 

Version Number 

2 bits 

Version of the Virtual 

VCDU Identifier (VCDU-ID): 
Spacecraft Identifier 

8 bits 

Channel Data Unit 
structure. 

Uniquely identifies 

Virtual Channel ID 

6 bits 

flight vehicle. 
Uniquely identifies 

Virtual Channel Data Unit Counter 

3 octets 

Virtual Channel. 
Provides running 

Signalling Field: 

1 octet 

count of VCDUs 
which have been 
transmitted on this 
Virtual Channel. 

Replay Flag 

1 bit 

Indicates whether or 

Reserved Spares 

7 bits 

not data has been 
recorded. 

Reserved for future 

Data Unit Zone: 

1 109 octets 

signalling applica- 
tions. 

M-PDU Header: 

2 octets 


Spare 

5 bits 

Currently undefined. 

First Header Pointer 

11 bits 

Points to first CCSDS 

User Data 

1107 octets 

Packet header. 

Reed-Solomon Check Symbols 

160 octets 

Provide error 


detection/correction 
for the entire VCDU. 


Part of the overhead associated with the CVCDU structure is fixed and part is vari- 
able. CVCDUs are separated by synchronization markers that are 4 octets long. A 
CVCDU together with its preceding synchronization marker is called a Channel Access 
Data Unit (CADU). Thus, the total length of a CADU for our configuration is 1279 
octets. The fixed overhead is 172 octets per CADU, including the synchronization 
marker, the VCDU header, the M-PDU header, and the Reed-Solomon Check Symbols. 
Hence, fixed overhead is 172/1279 = 13.4%. 

The user data field of a CVCDU consists of a multiplexed string of CCSDS Packets. 
Headers of these packets constitute variable overhead, because the number of packets 
contained in the user data field is variable. The size of a packet containing telemetry data 
varies from approximately 500 octets to 2000 octets, depending on the type of instru- 
ment. The average size is approximately 1000 octets. Engineering packets which 
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contain information for diagnosing the instruments will be shorter, approximately 100 
octets in length. 

By combining fixed overhead with variable overhead, channel efficiency can be 
computed over a range of packets per CVCDU. The resulting figures are more meaning- 
ful if channel efficiency is also computed when the CCSDS Packet structure in the 
CVCDU is replaced by a general-purpose packet structure. To obtain such a comparison, 
suppose that the packetizing structure for the VCDU data unit zone were the Internet Ser- 
vice Packet rather than the Path Service Packet, i.e., suppose that the VCDU data unit 
zone were a multiplexed string of ISO 8473 packets rather than CCSDS Packets. 
Because the ISO 8473 packet header is considerably larger than the CCSDS Packet 
header, this would substantially increase the variable part of the overhead associated with 
the CVCDU structure.* 

Figure 3 compares channel efficiency using CCSDS Packets for the VCDU data unit 
zone to channel efficiency using ISO 8473 packets instead, over a range of 1 to 8 packets 
per CVCDU. This is a reasonable range, based on the above packet sizes for telemetry 
data. Since the CCSDS Packet header is so short, efficiency decreases only slightly as 
packet size decreases. In contrast, if ISO 8473 Packets are used instead of CCSDS Pack- 
ets, packet-header overhead rapidly becomes significant as the number of packets per 
CVCDU increases. This figure illustrates the relative efficiency of using CCSDS Pack- 
ets. The advantage of using CCSDS Packets becomes more significant as the number of 
packets per CVCDU increases. For example, if there are 8 packets per CVCDU, channel 
efficiency when using CCSDS Packets is approximately 42% higher than when using 
ISO 8473 Packets. This is an impressive figure, especially since the space-to-ground 
channel is such a precious resource. 

4.3. Ground Processing of Path Service Data 

Path Service data must be processed when it reaches the ground to remove the 
artifacts introduced by onboard recording. The nature of this processing, called Level 
Zero Processing, will differ from agency to agency. When Level Zero Processing is cen- 
tralized, as NASA plans to do it, data can be completely reconstructed before it is for- 
warded to the end user. This includes reversing the data, removing overlaps between 
stored data and real-time data, and resequencing the packets. If Level Zero Processing is 
distributed, some of these functions may be performed by the end user. 

Level Zero Processing enables system complexity to be shifted from space to 
ground. This is highly desirable, because resource constraints are less stringent on the 
ground than in space. Also, it is more cost-effective and more reliable to provide pro- 
cessing power on the ground than in space. 


♦The length of the ISO 8473 header is variable. For our computation we assumed a header length 
of 45 octets. If upper layer protocols (e.g., a transport-layer protocol) are used in conjunction 
with ISO 8473, the length of the header would have to be appropriately increased. 
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FIGURE 3. COMPARISON OF SPACE-TO-GROUND CHANNEL 
EFFICIENCY, USING CCSDS PACKETS VS. USING ISO PACKETS 


4.4. Role of Management 

The reason Path Service is able to provide such efficient communications services 
to handle telemetry data is that a supportive communications infrastructure is 
preconfigured by network management prior to transmission of any data. This infrastruc- 
ture includes Logical Data Paths and Virtual Channels, along with specifications of per- 
tinent attributes, such as maxim um data rate and length of time an instrument will be 
turned on. The amount of overhead involved in this configuration process cannot be 
quantified at this time, because development of the management portion of the CCSDS 
recommendation has just begun. 

After management has configured the communications infrastructure to support 
each of the instrument payloads, a schedule can be developed that specifies when various 
instruments should be turned on. Such a schedule will ensure the availability of adequate 
resources to handle the communications load. 

5. Path Service Versus Internet Service 

Path Service is a special-purpose, high-performance service that was developed to 
support high-rate, high-volume applications, such as telemetry, which have static com- 
munications requirements over long periods of time. Internet Service supports interac- 
tive applications which have more traditional networking requirements. In this section 
we contrast the functionality of the two services, identify performance bottlenecks of 
each, and argue that general-purpose OSI protocols are inappropriate for Path Service 
applications. 
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5.1. Functionality 

Internet Service will interface above to the transport layer of the OSI network 
model. The combination of ISO 8473 and a transport-layer protocol, such as ISO TP-4 
[5], provides rich functionality to ensure reliable end-to-end data transmission for 
general-purpose applications. Specific functions provided by these layers include rout- 
ing, connection management, dynamic flow control, computation of checksums, handling 
of acknowledgements and retransmissions, resequencing of data at the receiver, and seg- 
mentation and reassembly. 

As indicated in earlier sections, Path Service provides few of these functions. Since 
communications requirements of Path Service applications are static over long periods of 
time, network management can preconfigure a communications infrastructure to support 
the application. Routing and static flow control are provided through this infrastructure. 
Dynamic flow control is not necessary.* Resequencing of data is done by Level Zero 
Processing after data reaches the ground. Path Service is a connectionless service; it 
does not guarantee end-to-end reliability, i.e., reliability from the space-borne instrument 
to the end user on the ground. Use of an acknowledgement and retransmission scheme 
for telemetry data over the lossy space-to-ground subnet is not anticipated, because of the 
associated cost. Hence, providing end-to-end reliability for Path Service over the 
onboard subnet would be wasteful of scarce resources. 

5.2. Performance Bottlenecks 

The primary bottleneck in general-purpose networks is processing at the network 
and transport layers of the OSI network model. For example, prototype network inter- 
face units (NIUs) that implement the ISO 8473 and ISO TP-4 protocols have been 
developed under NASA sponsorship for the Space Station Freedom Program. 
Throughput that was measured at 20 megabits per second at the data-link layer of one of 
these prototypes was reduced to less than 3 megabits per second at the transport layer [7]. 
Specific network/transport-layer performance bottlenecks that have been identified 
include buffer management, timer management, data copying, computation of check- 
sums, processing within the receiver, segmentation within gateways, and operating sys- 
tem overhead [1,2, 7,8]. 

Path Service is not subject to many of the above botdenecks. For example, because 
Path Service does not provide end-to-end reliability, the traditional problems associated 
with timers to handle acknowledgements and retransmissions are avoided. Some of the 
other bottlenecks listed above can be avoided, or at least their effects can be lessened, if 
the co mm unications infrastructure is appropriately configured. For example, buffer 
management can be optimized for Path Service, because packet length is likely to be 
fixed for a particular instrument In general, it is much easier to optimize for special- 
purpose applications than to optimize for general-purpose applications. 


♦Some Virtual Channels will be data-driven, rather than schedule-driven, to provide the flexibility 
to respond to unpredictable physical phenomena, such as the occurrence of solar flares. Possible 
techniques for dynamic flow control, which will be necessary to manage these data-driven Virtu- 
al Channels, are currently under investigation. 
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The major source of overhead for Path Service is likely to be the preconfiguration of 
Logical Data Paths and Virtual Channels. However, this overhead is incurred only once. 
Because of the static nature of the communications requirements for Path Service appli- 
cations, such preconfiguration will result in considerable savings in protocol processing 
and channel utilization. 

5.3. Inappropriateness of OSI Protocols for Path Service Applications 

Traditional general-purpose OSI protocols are not well-suited for Path Service 
applications because they are not designed to cope with the anomalies of the space- 
networking environment. Communications requirements for Path Service applications 
can be provided more efficiently by using a special-purpose protocol. 

General-purpose network/transport protocols that provide end-to-end reliability are 
unable to cope with the excessive delays introduced by the onboard recording of data. 
End-to-end connections, between the application onboard the spacecraft and the end user 
on the ground, would be difficult to manage. An end-to-end acknowledgement and 
retransmission scheme would needlessly congest the network, because timer thresholds 
that are reasonable to handle interactive applications would cause needless retransmis- 
sion of packets that have been delayed because of onboard recording. 

Internet Service will be used primarily for onboard applications or for interactive 
space-to-ground applications while the communications window is open. It is not 
intended for use with applications that will be subject to onboard recording. 

As we showed in Section 4, Path Service provides a streamlined means of handling 
high-rate, high-volume data with static source-destination pairings. The flexibility pro- 
vided by the OSI protocols is too wasteful of scarce space resources to be used for such 
structured applications. 

6. Conclusions 

Path Service is a high-performance service, optimized for the transmission of 
telemetry data from space to ground. The primary performance objectives are to minim- 
ize onboard protocol processing and to optimize use of bandwidth on the space-to- ground 
channel. Since telemetry data will account for the largest percentage of data that is gen- 
erated by space missions, efficient handling of this data significantly impacts overall sys- 
tem requirements. In this paper we have shown how Path Service provides both 
protocol-processing simplicity and channel efficiency, and we have argued that general- 
purpose protocols are inappropriate for Path Service applications. 

This is a preliminary study of performance issues related to CCSDS Path Service. 
Though we have qualitatively shown how Path Service simplifies protocol processing for 
applications typified by the telemetry application, it is premature to quantify these 
benefits because implementation issues are just now being addressed. 
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